In the payment industry, magnetic stripe cards currently have track data elements stored in data tracks (e.g., track 1 or track 2). Examples of track data elements include the cardholder's PAN (personal account number), CVV (card verification value), etc.
In a typical purchase transaction using a magnetic stripe card, a card is swiped at a point of sale terminal and data on the card are read by the point of sale terminal. The point of sale terminal then sends the data to the issuer of the card in an authorization request message. The authorization request message requests authorization from the issuer to proceed with the transaction. The issuer then receives the authorization request message and then approves or declines the request. An authorization response message including the approval or decline is then sent from the issuer back to the point of sale terminal to inform the merchant as to whether or not the transaction has been approved or declined.
There is a need to protect data as it is delivered from the point of sale terminal to the issuer. If the data passing between the point of sale terminal and the issuer is intercepted by an unauthorized person, the unauthorized person could conduct unauthorized financial transactions using the transaction data.
One way to provide greater security is to encrypt transaction data before it is sent from the point of sale terminal to the issuer. For example, in a conventional PIN (personal identification number) based transaction using a payment card, symmetric keys can be used to encrypt and decrypt a cardholder's PIN as it passes from the point of sale terminal to the issuer. To encrypt the PIN at the point of sale terminal, a symmetric key can be stored in a tamper-resistant HSM (hardware security module) coupled to a point of sale terminal. HSMs are usually in the form of a plug-in card (PCI) or external device. A corresponding symmetric key may be stored at the issuer and the issuer may use the corresponding symmetric key to decrypt the encrypted PIN.
While such conventional methods of encryption are effective for encrypting PINs, a number of improvements could be made. For example, although HSM modules can be used to encrypt PINs, they typically are specialized and expensive. A specialized terminal may cost on the order of $300-$600 in today's dollars. It would be desirable to provide for a security process which could use an HSM module, but does not require one.
In addition to cost and complexity, key management processes in conventional encryption processes could also be improved. For example, in conventional key management processes, key updates can be sent from the issuer or other entity to a POS terminal every hour or once per day. This can be a burdensome and expensive task as there can be thousands of POS terminals that need to be updated in a regular manner.
It is more difficult for an issuer or other party to send a symmetric key to a point of sale terminal, than it is to receive it. Point of sale terminals are constantly being installed, updated, modified, and removed, and an issuer (or other party who wants to receive encrypted transaction data) cannot know when all point of sale terminals are available to communicate with the issuer. For example, after a POS terminal is installed, it needs to notify an issuer that it exists. Once the issuer is notified, it can then send a symmetric key to the POS terminal. This process requires two-way communication between the issuer and the terminal in order to install symmetric keys. This two-way communication process increases the processing burden to any payment processing system, especially since there may be thousands of POS terminals being installed on a regular basis.
To improve the security of financial messages passing through a network, some have suggested generating transaction specific keys in a point of sale terminal and then sending the keys from the point of sale terminal to a remotely located controller along with transaction request messages for various transactions. While this may be an effective security process, sending a separate key for every transaction can also burden existing payment processing systems. It would also require POS terminals and issuers to maintain and use complex and expensive hardware and software.
Embodiments of the invention address these problems and other problems, individually and collectively.